REPRINT 


A  Network  Version  of  The  Pump 

Myong  H.  Kang,  Ira  S.  Moskowitz,  and  Daniel  C.  Lee 


FROM: 

Proceedings  of  1995  IEEE  Symposium  on  Security  and  Privacy,  pages  144  -  154,  Oakland,  CA  IEEE  Press,  1995. 


CONTACT: 

Myong  H.  Kang  or  Ira  S.  Moskowitz,  Information  Technology  Division,  Mail  Code  5540,  Naval  Research  Laboratory, 
Washington,  DC  20375. 


E-MAIL: 

mkang@itd.nrl.navy.mil 
moskowit,  @it  d .  nrl .  navy.mil 


Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1.  REPORT  DATE 

1995 

2.  REPORT  TYPE 

3.  DATES  COVERED 

00-00-1995  to  00-00-1995 

4.  TITLE  AND  SUBTITLE 

5a.  CONTRACT  NUMBER 

A  Network  Version  of  The  Pump 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROIECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Naval  Research  Laboratory, Code  5540,4555  Overlook  Avenue, 

SW, Washington, DC, 20375 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR'S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

15.  SUBIECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 
ABSTRACT 

18.  NUMBER 

OF  PAGES 

12 

19a.  NAME  OF 
RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


A  Network  Version  of  The  Pump 
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Abstract 

A  designer  of  reliable  MLS  networks  must  consider 
covert  channels  and  denial  of  service  attacks  in  addition 
to  traditional  network  performance  measures  such  as 
throughput,  fairness,  and  reliability.  In  this  paper  we 
show  how  to  extend  the  NRL  data  Pump  to  a  certain 
MLS  network  architecture  in  order  to  balance  the  re¬ 
quirements  of  congestion  control,  fairness,  good  perfor¬ 
mance,  and  reliability  against  those  of  minimal  threats 
from  covert  channels  and  denial  of  service  attacks.  We 
back  up  our  claims  with  simulation  results. 

1  Introduction 

In  a  MLS  system,  a  low  subject  (Low)  should  be  able 
to  send  information  to  a  high  subject  (High),  but  High 
should  not  be  able,  to  send  information  to  Low.  On 
the  other  hand,  acknowledgements  (ACIv)  to  Low  that 
High  has  received  its  messages  are  necessary  for  relia¬ 
bility  and  performance.  This  is  especially  true  for  dis¬ 
tributed  systems  in  which  the  communication  channels 
may  not  always  be  reliable.  High,  however,  Can  manip¬ 
ulate  the  times  that  ACIvs  arrive  in  order  to  covertly 
send  unauthorized  messages  to  Low. 

The  Pump,  developed  at  NRL  [3,  4],  solves  the 
dilemma  of  simultaneously  assuring  reliability,  perfor¬ 
mance  and  security.  We  will  refer  to  this  as  the  basic 
Pump.  The  basic  Pump  allows  High  to  send  ACIvs  to 
Low,  but  requires  that  Low  receive  them  at  probabilis¬ 
tic  time  intervals.  The  basic  Pump  bases  these  proba¬ 
bilistic  times  on  past  High  activity,  and  moderates  the 
ACIv  times  through  the  use  of  a  communication  buffer. 

Since  computer  systems  are  becoming  more  open  and 
interconnected,  denial  of  service  problems  are  receiving 
more  attention  [12].  Hence,  security  devices  should  also 
provide  protection  against  such  attacks. 

^Respective  addresses  of  the  authors  are  (mail  code  5540, 
mail  code  5540,  mail  code  8140)  Naval  Research  Labo¬ 
ratory,  Washington,  D.C.  20375.  Respective  e-mail  ad¬ 
dresses  are  mkang yitd.nrl.navy.mil,  moskowitz itd.nrl.navy.mil 
lee  y  king  crab.nrl.navy.mil 


This  paper  addresses  how  to  adapt,  the  basic  Pump 
for  use  in  a  network  environment,  where  we  have  mul¬ 
tiple  Lows  and  multiple  Highs.  We  will  refer  to  this 
as  the  “network  Pump.”  As  we  move  from  a  dedi¬ 
cated  data  and  copper  world  to  the  B-ISDN1  world  of 
ATM2,  the  issues  of  congestion  control,  fairness,  and 
reliability  become  extremely  important  and  extremely 
complicated.  The  network  community  itself  has  not 
worked  all  of  these  issues  out  yet.  Our  problem  is  even 
more  complex  because  we  are  coupling  security  (i.e., 
covert  channels  and  denial  of  service)  with  the  above. 

1.1  Assumptions  and  Terminology 

The  network  environment  that  is  considered  is  shown 
in  figure  1 . 

There  are  many  Lows  and  Highs,  and  they  are  un¬ 
trusted  processes.  The  network  Pump  is  a  trusted  pro¬ 
cess  which  mediates  traffic  from  Lows  to  Highs.  Each 
message  that  will  be  routed  from  a  Low  to  a  High  has 
a  message  number,  and  input  and  output  addresses  as¬ 
sociated  with  it.  For  simplicity,  we  assume  that  all 
messages  have  the  same  length.  We  do  not  consider 
multicasting  in  this  paper.  Lows  (Highs)  do  not  com¬ 
municate  among  themselves. 

A  session  is  a  communication  channel  between  any 
Low  and  any  High.  In  figure  1  there  are  I  x  J  distinct 
sessions.  During  each  session, y ,  a  message  leaves  Low,;, 
travels  over  link,;,  goes  into  the  network  Pump,  and 

1  Broadband  Integrated  Services  Digital  Network. 

2  Asynchronous  Transfer  Mode. 
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after  processing  leaves  the  network  Pump  over  linkJ , 
and  arrives  at  Highj.  We  assume  that  all  propagation 
delays  are  zero  for  conceptual  simplicity3.  The  minimal 
processing  time  of  the  network  Pump  is  a  set  overhead 
value  0V ,  which  is  small  enough  so  that  the  network 
Pump  itself  never  becomes  a  performance  bottleneck. 

The  input  rate  A ,y  is  the  rate  of  inputs  from  Low,; 
destined  for  Highj.  Hence,  j—  is  the  mean  interarrival 
time  of  inputs.  Each  Highj  behaves  as  a  server  with 
service  rate  p.,;j .  This  is  the  inverse  of  the  mean  time 
of  service  by  Highj  for  messages  from  Low,; . 
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Figure  2:  fairness 


1.2  Objectives 

Most,  network  resources  are  dynamically  shared  for  effi¬ 
ciency  reasons.  If  this  dynamic  sharing  is  not  carefully 
controlled  then  inefficiency  and  delays  occur  [1].  The 
main  functions  of  congestion  control  in  a  network  are: 

•  To  prevent  inputs  from  sending  messages  faster 
than  the  outputs  can  handle  them. 

•  To  prevent  throughput  degradation  and  loss  of  ef¬ 
ficiency  from  overloading  the  network. 

•  To  prevent  unfair  allocation  of  network  resources 
from  competing  inputs. 

Since  the  network  Pump  is  a  shared  resource  among 
many  sessions,  it  should  provide  the  congestion  con¬ 
trol  mechanism.  Let  us  discuss  the  specific  objectives 
required  of  t.h©1  network  Pump. 

Reliability  /  Handshaking 

The  reliability  requirement  can  be  simply  stated  as  no 
loss  of  messages  and  no  duplication  of  messages.  To 
satisfy  this  requirement  ACIvs  and  message  numbers 
(ID)  are  necessary.  The  network  Pump  has  a  reliability 
protocol  that  works  as  follows: 

If  a  Low  has  not  received  ACIv  by  time_out 
after  sending  a  message,  it  will  retransmit  the 
same  message.  If  a  High  receives  the  same 
message  then  it  will  keep  only  one  copy. 

Further,  a  Low  does  not  send  the  next  message  to 
a  specific  High  until  its  previous  message  to  that  High 
has  been  ACIved  (handshake  protocol). 

3  This  assumption  can  be  easily  relaxed. 


Performance 

We  desire  good  performance.  The  network  Pump  is  de¬ 
signed  to  achieve  this  by  exercising  congestion  control. 
The  network  Pump  controls  the  rates  into  itself  (input 
rates)  by  attempting  to  slave  the  input  rates  to  the  av¬ 
erage  rates  out  (service  rates)  of  the  network  Pump  by 
moderating  the  ACIv  rate  to  a  Low,  since  this  Low  will 
not  send  a  new  message  until  it  receives  an  ACIv  from 
the  previous  (session)  message. 

If  the  service  rates  are  greater  than  the  input  rates, 
then  the  network  Pump  should  not  hurt  performance. 
If  service  rates  are  less  than  the  input  rates,  then  the 
outputs  cannot  handle  their  inputs.  Therefore,  the  net¬ 
work  Pump  by  slowing  the  input  rate,  alleviates  con¬ 
gestion,  and  at  the  worst,  does  not  lessen  total  through¬ 
put. 

Fairness 

Bandwidth  of  communication  links,  transmission 
speed,  and  processing  speed  are  all  limited.  Therefore, 
if  the  load  of  data  traffic  offered  to  the  network  Pump 
exceeds  its  capability,  some  of  the  load  must  be  cut.. 
The  load  must,  be  cut.  fairly  for  all  the  sessions  that, 
share  the  network  Pump.  The  idea,  is  shown  in  figure 
2  where  the  output,  limitation  is  due  to  limited  output, 
link  capacity. 

Fairness  can  be  defined  in  different,  ways.  One  fair¬ 
ness  policy  is  max- min  fairness.  This  policy  says  all 
sessions  should  get.  bandwidth  according  to  the  follow¬ 
ing  criterion  —  the  smallest,  allocated  rate  is  as  large 
as  possible  and,  given  this,  the  second-smallest,  allo¬ 
cated  rate  is  as  large  as  possible,  etc. [2].  For  example, 
if  there  are  three  sessions  whose  demand  rates  are  0.4, 
0.5,  0.6  and  the  output,  capacity  equals  1  then  all  three 
sessions  will  be  allocated  rates  of  1/3,  1/3,  1/3  under 
max-min  fairness.  If  one  session  demands  less  than 
what.  it.  can  get.,  the  leftover  bandwidth  will  be  equally 
shared  among  the  rest,  of  the  sessions.  For  example, 
if  i  In  H  are  three  sessions  whose  demand  rates  are  0.2, 
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0.5,  0.6  and  the  output  capacity  equals  1  then  those 
sessions  will  be  allocated  0.2,  0.4,  0.4,  respectively  un¬ 
der  max- min  fairness. 

The  advantages  of  this  policy  are  ( 1 )  there  is  a  simple 
way  to  implement  this  policy  (i.e. ,  round-robin  schedul¬ 
ing  [2] )  and  ( 2 )  the  scheduling  scheme  does  not  need 
to  know  the  demand  rates  of  sessions  which  may  not 
always  be  known.  Since  this  policy  gives  preference  to 
sessions  that  have  lower  demand  rate,  it  does  not  al¬ 
low  a  session  to  take  the  entire  bandwidth  if  there  is 
more  than  one  session.  One  disadvantage  of  this  policy 
is  that  a  heavily  demanded  session  is  penalized  more 
than  a  lightly  demanded  session  (i.e.,  not  sensitive  to 
demand  rates). 

There  are  other  fairness  policies  such  as  the  propor¬ 
tional  policy  [11].  This  policy  allocates  bandwidth  in 
proportion  to  each  input  demand.  The  network  com¬ 
munity  does  not  have  a  “best”  fairness  policy.  The 
network  Pump  uses  max-min  fairness  because  of  the 
above  advantages. 

Covert  Channels 

It  is  well  known  that  the  ACIv  stream  that  is  required 
to  satisfy  the  reliability  requirement  introduces  covert 
channels.  This  was  the  motivation  for  developing  the 
basic  Pump  over  the  conventional  store  and  forward 
buffer  type  of  communication.  We  will  show  in  section 
3.2,  as  we  did  in  [3,  4]  that  the  capacity  of  the  covert 
channels  can  be  made  negligible. 

Denial  of  Service 

We  interpret  the  denial  of  service  attack  in  a  broad 
sense  in  the  network  environment; 

If  a  session  cannot  achieve  its  intended 
throughput  due  to  the  misbehavior  of  other 
sessions  then  the  session  is  under  a  denial  of 
service  attack. 

Since  the  network  Pump  is  a  shared  resource  among 
several  sessions,  services  for  other  sessions  can  be  po¬ 
tentially  disrupted  if  too  much  resource  is  allocated  to 
one  particular  session.  The  design  of  the  network  Pump 
should  prevent  such  a  situation. 

2  Background  —  The  Basic 
Pump 

In  the  basic  Pump  our  concern  is  sending  messages 
from  (one)  Low  to  (one)  High.  In  [3,  4],  we  re¬ 
viewed  why  traditional  communication  protocols  (in- 


Figure  3:  The  Basic  Pump 


eluding  read-down  and  blind  write-up)  cannot  satisfy 
the  needs  for  reliability,  performance,  and  security  si¬ 
multaneously.  As  a  solution,  the  basic  Pump  was  in¬ 
troduced  as  shown  in  figure  3. 

The  basic  Pump  [3]  places  a  buffer  (size  n)  between 
Low  and  High,  and  gives  ACIvs  at  probabilistic  times 
to  Low  based  upon  a  moving  average  (M A)  of  the 
past  m  High  ACIv  times.  A  High  ACIv  time  is  the 
time  from  when  the  buffer  sends  a  message  to  High 
to  the  time  when  High  sends  an  ACIv  back.  This  has 
the  double  benefit  of  keeping  the  buffer  from  filling  up 
and  having  a  minimal  negative  impact  upon  perfor¬ 
mance.  The  actual  ACIv  time  to  Low  is,  if  there  was 
space  on  the  buffer  when  Low  sent  the  message,  an 
exponential  random  variable  with  mean  equal  to  M A, 
shifted  by  an  amount  of  time  equal  to  the  minimum 
processing  time  of  a  message.  When  Low  must  wait, 
for  space  on  the  buffer  the  shift  is  equal  to  maa;(wait 
time  for  space,  minimum  processing  time).  (In  [4]  we 
have  slightly  modified  this  over  the  first,  exposition  of 
the  basic  Pump  [3]  to  introduce  extra,  noise.  However, 
for  the  network  Pump  we  stay  with  the  simpler  formu¬ 
lation.) 

At  present,  the  basic  Pump  has  been  built  by  HFSI 
to  run  on  a,  XTS-300  platform.  Also  the  basic  Pump  is 
being  built  as  a,  device  by  the  prototype  laboratory  of 
NRL’s  Center  for  High  Assurance  Computer  Systems. 
Early  results,  along  with  the  simulation  results  of  Ivang 
and  Moskowit.z  [4],  show  a,  proof  of  concept  for  the 
basic  Pump.  Based  upon  this  and  the  need  for  a,  secure 
network  congestion  mediator  we  feel  the  extension  to 
the  network  environment  is  warranted. 


3  An  Architecture  of  the 
Network  Pump 

The  architecture  of  a,  network  Pump  is  shown  in  figure 
4. 

Each  component  of  the  network  Pump  works  as  follows: 

Lows  and  Highs:  (Exterior  to  the  network  Pump) 

Lows  (Highs)  is  the  set  of  inputs  (outputs)  to  the 
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buffer,j 

buffer^ 

• 

buffer^ 

Figure  5:  A  closer  view  of  a  trusted  high  process. 


Figure  4:  A  logical  view  of  the  network  Pump. 

network  Pump.  Lows  (Highs)  consists  of  7  (J) 
non-communicating  among  themselves  processes. 
Each  input  can  send  messages  to  any  output,  with 
various  rates  as  discussed  before.  Since  Low,;  is 
outside  of  the  network  Pump  we  assume  the  Low,; 
has  some  procedure  for  sending  messages  over 
link,;,  the  only  constraint  being  that  the  rates  are 
A ,y,  such  that  JA  A,y  <  capacity  of  link,;.  Con¬ 
sider  session, y  —  After  Low,;  sends  a  message  to 
Highj ,  it  waits  for  the  ACIv  to  that  message  from 
the  network  Pump.  Once  this  ACIv  arrives,  Low,; 
can  send  another  message  to  Highj.  Therefore, 
bach  Low  can  send  only  one  message  in  each  ses¬ 
sion  without  receiving  the  ACIv  to  the  previous 
message  from  the  network  Pump  (handshake  pro¬ 
tocol).  When  Highj  receives  a  message  from  the 
network  Pump  it  sends  an  ACIv  back  after  the  ap¬ 
propriate  service  time  to  the  network  Pump. 

Receivers 

There  is  one  receiver,;  for  Low,;.  In  each  receiver, 
there  are  J  slots;  slot  j  stores  a  messages  from 
session, y  until  it  is  routed  by  the  TLP. 

Trusted  Low  Process  (TLP): 

The  TLP  takes  a  message  from  a  receiver  and 
routes  it  to  the  appropriate  output  buffer.  We 
denote  by  Tr  the  time  from  when  a  message  is 
sent  from  a  Low  to  the  time  when  that  message  is 
placed  in  the  appropriate  output  buffer.  (We  will 
also  refer  to  Tr  as  “routing  time.”  )  If  there  is  avail¬ 
able  space  in  the  output  buffer,  Tr  is  equal  to  the 
overhead  Ov .  If  there  is  no  space,  the  message  is 
not  placed  until  there  is  a  spaqq  available.  There¬ 
fore,  Tr  includes  both  Ov  and  the  amount  of  time 
the  message  waits  until  the  output  buffer  is  avail¬ 
able.  After  the  message  is  routed  to  the  output 
buffer,  the  TLP  is  ready  to  send  an  ACIv  back  to 
the  appropriate  Low,;.  The  time  this  ACIv  arrives 


at  Low,;  depends  on  the  randomization  scheme, 
but  is  always  at  least  Tr . 

Output  Buffers 

There  are  I  logical  output  buffers  for  Hj ,  denoted 
by  buffer, ;j .  A  message  from  session, y  will  be 
stored  in  buffer, y . 

Trusted  High  Processes  (THP): 

THPj  delivers  a  message  from  buffer, y  to  Highj  ac¬ 
cording  to  a  scheduling  scheme.  THPj  cannot  de¬ 
liver  another  message  from  buffer, y  until  the  prior 
message  from  buffer, y  is  ACIved  (by  Highj). 

3.1  A  Detailed  Design 

A  detailed  design  rationale  is  described  in  this  section. 

3.1.1  Trusted  High  Processes 

THPj  plays  an  important  role  in  scheduling  delivery 
from  output  buffers  to  Highj  and  in  computing  moving 
averages.  Figure  5  graphically  describes  the  role  of  a 

THP,. 

Consider  THPj  —  it  has  to  deliver  messages  from 
each  buffer, y  to  Highj .  Since  the  capacity  of  linkJ  is 
limited  by  physical  considerations  and  inputs  may  send 
more  messages  than  linkJ  or  Highj  can  handle,  THPj 
needs  some  scheduling  scheme.  This  scheduling  scheme 
determines  the  fairness  among  different  inputs. 

The  network  Pump  uses  round-robin  scheduling  be¬ 
cause  it  is  simple  and  achieves  max-min  fairness  [2]. 
For  example,  if  THPj  has  to  serve  three  output  buffers 
then  an  opportunity  to  send  a  message  is  given  in  the 
order  of  buffer^,  buffer  2  j ,  buffei-3j ,  buffer^,  ...  .  If 

bufferoj  does  not  have  any  message  to  send  then  the 
opportunity  is  transferred  to  buffei-3j  and  the  next  op¬ 
portunity  is  given  to  buffer jy ,  and  so  on. 

THPj  also  maintains  and  updates  moving  averages 
(MAij,  ...,  MAjj).  The  reason  for  THPj  to  maintain 
I  moving  averages  (i.e. ,  one  per  session)  instead  of  one 
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moving  average  is  that  Highj  may  have  different  ser¬ 
vice  times  for  messages  from  different  Lows.  Through¬ 
out  this  paper  we  assume  the  message  service  time  is 
not  a  performance  bottleneck  in  the  benign  case.  In 
other  words,  the  bottleneck  is  output  links,  not  servers., 
unless  the  system  is  under  denial  of  service  or  covert 
channel  attacks. 

Since  there  is  potentially  more  than  one  input,  the 
method  of  computing  moving  averages  is  different  from 
when  there  is  only  one  input.  When  there  is  only  one 
input,  the  moving  average  is  computed  based  on  the 
interval  from  the  time  the  message  is  sent  to  the  time 
the  ACIv  arrived  from  High.  However,  if  1 1 1 < : »•< •  is  more 
than  one  input  then  the  message  is  ready  to  be  sent 
but  cannot  be  sent  because  the  output  link  is  not  avail¬ 
able.  This  additional  waiting  time  must  be  taken  into 
account  or  else  the  input  messages  will  flood  the  output 
buffers. 

M Aij  of  the  network  Pump  is  the  moving  average  of 
the  last  m  Highj  ACIv  times  of  messages  from  buffer, y  . 
A  Highj  ACIv  time  is  the  difference  between  when 
Highj  ACIvs  a  message  from  a  buffer, y  and  maa;(time 
that  message  arrived  in  buffer, y  ,  time  that  the  previ¬ 
ous  message  from  buffer, y  was  ACIved  by  Highj).  In 
other  words,  if  the  buffer,; j  is  not  empty  then  previous 
ACIv  time  by  Highj  is  used  to  compute  the  moving  av¬ 
erage.  However,  if  the  buffer, y  is  empty  when  a  new 
message  arrives  then  we  use  the  arrival  time  instead  of 
the  previous  ACIv  time. 

3.1.2  Output  Buffers 

The  number  of  messages  in  buffer, y  is  important  to 
achieve  fairness  [2]  (the  bigger  the  number  of  mes¬ 
sages  in  buffer, y  the  fairer).  This  is  because  our  round- 
robin  scheduler  does  not  take  burst.iness  into  account. 
The  way  to  handle  bursts  is  to  have  enough  messages 
queued  in  buffer, y  so  that  times  of  abundance  and  star¬ 
vation  (with  respect  to  message  arrivals)  are  balanced 
out.  In  fact,  it  is  desirable  to  keep  the  queue  length  in 
session, ;j  positive  so  that  max-min  fairness  is  preserved. 
However,  if  the  queue  length  is  too  big  we  have  covert 
channel  and  denial  of  service  problems.  Therefore,  it 
is  desirable  to  keep  the  queue  length  at  a  certain  level, 
which  is  referred  to  as  the  Fair  size ,  and  which  we  leave 
as  a  design  parameter  (of  course  the  burst.ier  the  input 
the  larger  the  fair  size  must  be).  Figure  6  shows  buffer, y 
where  the  number  of  messages  in  the  buffer  fluctuates 
around  the  Fair  size. 

Since  the  network  Pump  has  a  built-in  mechanism 
to  share  output  buffers  fairly  among  different  sessions 
(i.e. ,  moving  average  construction  to  control  input  rates 
which  will  be  discussed  in  section  3.1.3),  all  output 


Fair  Size 


Figure  6:  A  closer  view  of  buffer ,y . 

buffers  are  dynamically  shared  among  different  ses¬ 
sions. 

3.1.3  Trusted  Low  Process 

When  routing  requests  arrive  from  receivers,  the  TLP 
routes  messages  to  the  proper  output  buffers  and  reads 
the  current  moving  average  value.  Once  the  mes¬ 
sage  is  delivered,  the  TLP  is  ready  to  send  an  ACIv. 
However,  this  ACIv  will  be  delayed  depending  on  the 
moving  average  of  the  session  and  the  randomization 
scheme.  The  network  Pump  uses  a  similar  random¬ 
ization  scheme  as  the  basic  Pump  whose  details  are 
presented  in  [3,  4].  In  simple  terms,  the  TLP  of  the 
basic  Pump  delays  ACIv  based  on  the  exponential  ran¬ 
dom  distribution  whose  mean  is  the  moving  average  of 
the  session.  This  ACIv  rate  controls  the  input  rates  if 
the  input  rate  is  higher  than  the  service  rate  due  to  the 
handshake  protocol. 

As  we  discussed  in  section  3.1.2  we  wish  to  make 
sure  that  the  number  of  messages  in  an  output  buffer 
fluctuates  around  the  Fair  size.  To  achieve  this,  we 
modify  the  ACIv  scheme  from  the  basic  Pump.  The 
way  the  basic  Pump  controls  the  ACIv  time  to  Low 
can  be  written  as  follows: 

ACK  time  = 

Tr  if  MA  -  Tr  <  0 

min(  Tr  +  fr(M A  —  Tr)  ,  time_out  )  otherwise 
where  Tr  is  routing  time,  fr(x)  is  a  draw  from  an  expo¬ 
nential  random  distribution  with  mean  x,  and  MA  is 
the  moving  average  of  the  ACK  time  from  High  to  the 
basic  Pump.  (Note  that  there  is  only  one  session  in  the 
basic  Pump.)  Recall  that  Tr  is  the  time  between  when 
the  a  message  is  sent  from  Low  to  when  the  message 
is  placed  in  the  output  buffer.  Hence,  a  random  delay 
is  included  in  the  ACK  time  in  addition  to  the  routing 
time  if  MA  —  Tr>  0. 

We  now  describe  the  way  the  Network  Pump  con¬ 
trols  ACK  times  to  Low,;  for  a  message  in  each  session. 
Define 

Q  =  fr(MA{j  —  Tr)  +  k  ■  (N  —  Fair  size) 
whte  N  is  the  number  of  messages  in  buffer, y  at  the 
time  the  message  is  placed  in  buffer, y ,  and  k  is  a  design 
parameter  that  can  be  varied.  Note  that  the  moving 
average  of  the  ACK  times  from  Highj  to  the  network 
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Pump  is  computed  separately  for  each  session.  For 
session^-,  the  ACK  time  to  Low  for  each  message  is: 
ACK  time  = 

f  Tr  if  M Aij  —  Tr  <  0  or  Q  <  0 
(  min(  Tr  +  Q,  time_out  )  otherwise. 

We  now  elaborate  the  rationale  of  the  extra  term 
k  ■  ( N  —  Fair  size )  in  Q.  As  long  as  Low8-  has  mes¬ 
sages  to  send  to  Highj ,  the  network  Pump  wants  to 
keep  buffer^-  nonempty.  The  reason  is  to  prevent  miss¬ 
ing  the  round-robin  turn,  and  thus  to  give  each  session 
throughput  close  to  max-min  fairness.  Therefore,  when 
the  number  of  messages  in  buffer^-  is  less  than  the  Fair 
size,  the  network  Pump  reduces  its  ACK  time  to  Low 
in  order  to  accelerate  the  input  rate,  as  seen  in  the  ex¬ 
tra  term.  On  the  other  hand,  if  buffer^-  is  often  full,  we 
have  covert  channel  problems  (see  section  3.2).  Hence, 
the  network  Pump  decreases  the  input  rate  by  increas¬ 
ing  the  ACK  time  to  Low  when  the  number  of  messages 
in  buffer^-  is  larger  than  the  Fair  size.  Both  k  and  the 
Fair  size  are  design  parameters  that  can  be  chosen. 

In  the  simulation  that  is  described  in  section  4,  we 
use  k  =  M Aij /(Fair  size).  Thus 

0  =  fr(MAij  -  Tr)  +  -  1). 

Therefore,  we  have 

avg(ACK  time )  «  Tr  +  avg(Q)  = 

Note  that  avg(N)  is  close  to  the  Fair  size  due  to  the 
second  term  of  Q.  Thus  we  have  avg(AC'K  time)  x, 
MAij. 

3.1.4  Receivers 

Receivers  receive  messages  from  Lows  and  request  rout¬ 
ing  to  the  TLP.  Each  receiver  contains  J  temporary 
(size  one)  buffers  so  that  the  inputs  from  one  session 
do  not  interfere  with  inputs  from  other  sessions.  Mes¬ 
sages  in  the  temporary  buffers  will  either  be  routed  or 
discarded  after  time_out  (if  there  is  no  output  buffer 
available) . 

3.2  Design  Review 

In  this  section,  we  review  the  design  of  the  network 
Pump  and  explain  how  the  objectives  in  section  1.2  are 
satisfied.  We  back  our  claims  on  performance,  fairness, 
and  denial  of  service  by  the  simulation  results  presented 
in  section  4. 

Reliability 

Due  to  the  reliability  protocol  requirement  that  was 
specified  in  section  1.2  (i.e. ,  ACK,  retransmission  of 
the  same  message  after  time_out,  and  message  ID), 


the  network  Pump  provides  a  higher  level  of  reliability 
than  TCP/IP. 

Performance 

The  network  Pump  does  not  hurt  performance 
(throughput).  Consider  the  following  two  cases: 

•  Input  rate  is  faster  than  the  service  rate:  The  net¬ 
work  Pump’s  ACK  rate  which  is  tied  to  the  mov¬ 
ing  average  of  the  server  will  slow  down  input  to 
match  the  servers.  However,  this  will  not  degrade 
performance  because  the  throughput  will  be  deter¬ 
mined  by  the  service  rate  which  is  the  performance 
bottleneck. 

•  Input  rate  is  slower  than  the  service  rate:  The  net¬ 
work  Pump’s  ACK  rate  will  not  slow  down  the  in¬ 
put  rate  in  this  case.  Hence,  there  is  no  effect  on 
performance. 

Hence,  the  network  Pump  does  not  affect  the  through¬ 
put  unless  the  network  Pump  itself  is  the  bottleneck. 

Fairness 

The  network  Pump  uses  a  round-robin  scheduling 
scheme  which  enforces  max-min  fairness  at  THPjS  if 
all  inputs  can  accumulate  enough  messages  at  output 
buffers.  The  network  Pump’s  modified  moving  average 
construction  that  was  described  in  section  3.1.3  encour¬ 
ages  all  inputs  to  send  as  many  messages  as  possible 
up  to  the  Fair  size.  Hence,  the  network  Pump  achieves 
max-min  fairness. 

Covert  Channel  Analysis 

In  [4]  we  discussed  how  ACKs  can  cause  a  communi¬ 
cation  channel  from  High  to  Low  in  the  basic  Pump. 
Obviously  we  have  the  same  concern  with  the  network 
Pump.  Let  us  review  the  full  buffer  channel  (FBC) 
from  the  basic  Pump  and  see  its  impact  upon  the  covert 
covert  channel  analysis  of  the  network  Pump.  We  then 
discuss  how  a  Trojan  horse  might  use  ACKs  to  form  a 
statistical  channel  (exploitation  strategy  3  in  [3,  4],  see 
also  [9]  ). 

The  basic  Pump  was  designed  as  a  secure  version  of 
a  standard  store  and  forward  buffer  (SAFB).  The  ba¬ 
sic  Pump  without  probabilistic  delay  is  the  same  as  the 
SAFB.  In  a  SAFB  the  High  service  rate  can  slow  down 
so  that  it  is  less  than  the  Low  input  rate.  This  will 
cause  the  buffer  to  become  full.  Low  now  attempts  to 
insert  a  message  into  the  buffer  and  must  wait  until  ei¬ 
ther  a  time_out  or  until  High  finally  ACKs  a  message 
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to  the  basic  Pump  —  thereby  creating  space  on  the 
buffer  so  that  Low  can  insert  its  message  and  therefore 
receive  an  ACK.  High  and  Low  can  now  play  this  game 
of  High  ACKing  a  message  whenever  it  wants  (within 
the  limits  of  the  smallest  amounts  of  manipulable  time) 
and  this  time  being  exactly  reflected  to  Low  (modulo 
overhead  times).  This  forms  the  FBC  from  High  to 
Low.  In  [3,  4]  we  analyzed  the  capacity  of  this  covert 
channel.  The  FBC  capacity  is  simply  the  logarithm 
of  the  root  of  certain  polynomials  [7,  8].  However,  if 
we  use  the  basic  Pump,  the  probabilistic  arrival  times 
of  the  ACKs  introduce  noise  into  the  communication 
channel.  Also,  the  basic  Pump  prevents  the  buffer  from 
becoming/staying  full.  These  two  effects,  the  noise  and 
the  fact  that  the  buffer  is  hardly  ever  full,  severely 
diminish  the  capacity4  of  various  exploitations  of  the 
FBC.  Bounds  on  the  capacity  reductions  are  discussed 
in  [3]  and  exactly  given  in  [4].  In  brief,  a  relationship 
between  the  buffer  size  n  and  the  moving  average  MA 
was  given  with  respect  to  the  desired  percent  reduction 
of  the  covert  channel  capacity. 

In  the  network  Pump  our  Trojan  horse  scenario  is 
that  one  particular  High,-  and  one  particular  Low8-  are 
in  cahoots  via  cooperating  Trojan  horses  (recall  that  we 
are  looking  at  the  situation  where  the  Lows  (Highs)  do 
not  communicate  among  themselves).  In  the  network 
Pump  we  have  even  more  noise  introduced  into  the 
channel  by  the  multiple  users.  Also,  in  the  network 
Pump  instead  of  just  attempting  to  keep  the  buffer 
from  become  full  we  attempt  to  keep  the  buffer  around 
the  Fair  size  —  this  further  reduces  the  usefulness  of  the 
FBC.  Therefore,  we  can  use  the  capacity  bounds  from 
[4]  as  a  rough  upper  bound  (we  can  very  conservatively 
replace  n  by  the  Fair  size).  This  bound  becomes  even 
rougher  as  I  and  J  increase. 

In  the  basic  Pump  there  is  a  statistical  channel  [9] 
from  High  to  Low,  when  the  buffer  is  not  full,  caused  by 
Low  attempting  to  correlate  the  ACK  times  to  High’s 
actions.  As  the  number  of  terms  making  up  the  moving 
average  grows  this  correlation,  and  hence  the  channel 
capacity,  decrease.  The  same  holds  as  well  for  the  net¬ 
work  Pump  and  again  the  multiple  users  introduce  spu¬ 
rious  noise  which  further  serves  to  confound  any  mean¬ 
ingful  interpretation  of  the  ACK  times.  Also,  the  Fair 
size  further  frustrates  correlation  attempts  by  Low8-. 
Therefore,  the  bounds  from  the  basic  Pump  again  hold. 

Finally,  the  network  Pump  (as  well  as  the  basic 
Pump)  is  sensitive  to  the  small  message  criterion  [10]. 
By  this  we  mean  even  if  one  has  a  channel  with  small, 
or  even  zero,  capacity  it  might  still  be  possible  to  send 

4 Here,  unlike  the  rest  of  the  paper,  we  use  the  term  capacity 
in  Shannon’s  information  theoretic  sense  [13]- 


small,  possibly  noisy,  messages  in  relatively  quick  time. 
The  network  Pump  is  designed  to  thwart  such  a  covert 
communication  attempt.  We  will  not  go  into  further 
details  here. 

Denial  of  Service 

In  the  network  environment  denial  of  service  can  occur 
in  the  following  two  cases: 

1.  A  server  slows  down. 

2.  An  input  sends  messages  faster  than  the  rate  that 
the  intended  server  can  handle. 

In  these  cases,  the  shared  resources  will  be  monopolized 
by  this  specific  session  so  that  other  sessions  cannot  use 
required  resources. 

The  above  cases  will  not  happen  if  the  network  Pump 
mediates  between  the  Lows  and  Highs  because  the  net¬ 
work  Pump  monitors  the  servers’  activities  and  deter¬ 
mines  service  rates.  The  service  rate  will  be  reflected  to 
the  ACK  rate  to  Low8-  through  the  moving  average  con¬ 
struction.  Due  to  the  network  Pump’s  handshake  pro¬ 
tocol  and  moving  average  construction,  inputs  (Lows) 
cannot  send  any  more  than  the  servers  (Highs)  can  han¬ 
dle. 

4  Simulation  Results 

To  substantiate  our  claims  on  performance,  fairness 
and  denial  of  service,  simulation  experiments  have  been 
conducted. 

4.1  Simulation  Set  Up 

In  our  simulation  scenario,  there  are  three  Lows 
(L i,  L'p,  Ls)  and  three  Highs  (Hi,  H 2,  H3)]  hence  9  ses¬ 
sions.  The  capacities  of  all  input  and  output  links  are 
1.0.  All  inputs  have  Poisson  arrival  distributions5.  In¬ 
put  rates  from  L\  are  An  =  0.5,  A12  =  0.3,  A13  =  0.2, 
the  input  rates  from  L 2  are  A21  =  0.4,  A22  =  0.4, 
A23  =  0.2,  and  the  input  rates  from  L3  are  A31  = 
0.4,  A32  =  0.5,  A33  =  0.1  (see  figure  7). 

All  Highs  have  2-Erlang  distributed  service  rates  [5]. 
For  the  benign  case  all  service  rates  are  set  to  2.0.  For 
denial  of  service  simulation,  service  rates  are  fin  =  2.0, 
Hi 2  =  0.1,  and  Hi3  =  2.0  for  i  =  1,  2,  3. 

5This  is  an  idealized  input  rate.  Since  we  have  congestion 
control  this  is  not  achieved.  In  our  simulation  we  generate,  in  a 
Poisson  manner,  a  certain  number  of  messages  which  accumulate 
in  a  queue.  When  this  queue  is  filled  the  generation  stops  and 
starts  up  again  when  this  queue  again  has  space  in  it. 
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Figure  7:  The  simulation  scenario. 


The  performance  and  fairness  of  the  following  two 
systems  and  the  “ideal”  case  are  compared  under  dif¬ 
ferent  total  output  buffer  sizes. 

•  The  network  Pump  as  described  in  section  3.  The 
last  30  High  ACIv  times  are  used  to  compute  the 
moving  average  ( i.e. ,  m  =  30)  and  the  Fair  size 
per  session  was  set  to  y-j  of  the  total  output  buffer 
size.  Note  that  there  are  9  sessions  in  our  scenario. 

•  The  Nonpump.  This  is  the  same  as  the  network 
Pump  (still  has  the  handshake  protocol)  except 
that  it  does  not  have  the  moving  average  or  prob¬ 
abilistic  construction.  (Thus,  output  buffers  are 
allocated  to  each  session  on  a  first  come  first  serve 
basis.)  In  other  words,  ACIvs  will  be  sent  to  Lows 
as  soon  as  the  message  is  routed.  Hence,  input 
rates  will  be  forcibly  adjusted  only  when  there  are 
no  available  output  buffers.  The  purpose  of  this 
system  is  to  demonstrate  the  importance  of  con¬ 
gestion  control. 

•  The  ideal  case  is  where  the  max-min  fairness  rates 
are  achieved  over  the  output  links.  The  max-min 
rates  for  Hi  are  (1/3,  1/3,  1/3),  for  H3  they  are 
(0.3,  0.35,  0.35),  and  for  H3  they  are  (0.2,  0.2, 
0.1).  Hence  these  are  the  ideal  versions  to  which 
we  compare  the  network  Pump  and  Nonpump. 

4.2  Simulation  Results  in  the  Benign 
Case 

In  the  benign  case  (i.e.,  inputs  and  outputs  behave  — 
no  Trojan  horses  are  present),  there  is  not  much  of 
a  performance  difference  between  the  network  Pump 
and  Nonpump  even  though  the  network  Pump  per¬ 
forms  slightly  better  than  the  Nonpump.  This  slight 
performance  difference  comes  from  the  congestion  con¬ 
trol  mechanism.  Since  the  Nonpump  has  little  conges¬ 
tion  control,  some  inputs  still  send  more  messages  than 
the  intended  server  can  handle.  This  causes  an  unfair 
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Figure  8:  Throughput  of  session^. 
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Figure  9:  Throughput  of  sessionoo- 


sharing  of  resources  and  degrades  performance.  This 
effect  will  be  magnified  under  the  denial  of  service  at¬ 
tack.  Figures  8,  9,  and  10  show  the  performance  and 
fairness  among  sessions  that  send  messages  to  H'>. 

Since  session  12  has  less  input  rate  than  it  is  entitled 
to  (1/3),  it  achieves  its  demand  rate  as  allocation  rate. 
A  little  jitter  in  figure  8  is  from  the  probablistic  na¬ 
ture  of  the  input  rather  than  any  effects  from  routing 
devices13.  This  probabilistic  jitter  slightly  affects  the 
throughput  of  other  sessions  (figures  9  and  10). 

Figures  9  and  10  also  show  the  effect  of  the  sched¬ 
uler,  and  the  size  of  the  output  buffer  and  the  Fair  size 
to  the  fairness  and  throughput  of  each  session,  since 
0.4  and  0.5  are  both  greater  than  0.35.  As  the  size  of 

6The  rate  of  0.3  is  less  that  1/3  (the  max-min  rate).  The 
simulator  never  exactly  generates  a  rate  of  0.3,  hence  the  jitter. 
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Figure  10:  Throughput  of  sessioii32. 


Figure  11:  Throughput  ofsessionn. 


output  buffer  grows  the  throughput  approaches  to  its 
ideal  fairness  rate. 

Even  though  we  do  not  show  the  performance  of 
other  sessions  due  to  space  limitations,  the  network 
Pump  performs  very  well  (basically  the  same  as  in  fig¬ 
ures  11-16). 

4.3  Simulation  Results  under  Denial  of 
Service  Attack 

To  show  the  effect  of  denial  of  service  attack,  we  slow 
down  the  service  rate  (i.e. ,  p.,;2  =  0.1)  of  one  High, 
namely  H'>.  Figures  11  through  16  shows  the  perfor¬ 
mance  and  fairness  comparison  between  the  network 
Pump  and  the  Nonpump.  The  performance  of  the  net¬ 
work  Pump  is  hardly  affected  by  the  attack.  However, 
the  performance  of  the  Nonpump  is  greatly  affected. 
The  main  reason  for  the  degradation  of  performance 
is  that  all  output  buffers  are  occupied  by  sessions  that 
send  messages  to  H 2  so  that  the  rest  of  sessions  have 
to  wait,  a  long  time  to  obtain  them. 

Figures  11,  12,  and  13  show  the  throughputs  of  ses¬ 
sions  to  Hi. 

These  figures  (11,  12,  and  13)  show  no  jitter  of 
throughput  as  the  size  of  buffer  increases.  This  shows 
that  the  probablist.ic  nature  of  inputs  are  all  hidden 
because  all  input  (demand)  rates  to  H 1  are  greater 
than  its  allocation  rate  and  messages  are  always  wait¬ 
ing  for  their  turn  at  the  output  buffer'  (the  round-robin 
scheme  takes  a  message  from  each  buffer  in  turn  and 
does  not  pass  any  buffer  because  they  always  have  a 

'  For  example  a  fluctuation  around  a  rate  of  0.5  is  not  sig¬ 
nificant  when  the  (effective)  allocated  rate  is  actually  much  less 
than  0.5  . 
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Figure  12:  Throughput  ofsessiomi. 
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Figure  13:  Throughput  of  sessional. 
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Figure  14:  Throughput  of  session^.  Figure  16:  Throughput  of  sessions. 
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Figure  15:  Throughput  ofsessioii23. 
message  ready  to  send). 

Figures  14,  15,  and  16  show  the  throughputs  of  dif¬ 
ferent  inputs  to  H 3.  Again  the  jitter  of  throughput  is 
from  the  probabilistic  nature  of  inputs  rather  than  the 
effect  of  different  buffer  sizes. 

We  do  not  show  throughputs  of  session^,  sessionoo, 
sessioii32  because  under  the  denial  of  service  attack  aH 
cases  have  throughput  values  around  0.033. 

5  Summary 

This  paper  describes  the  need  for  a  secure  device  that 
can  route  messages  from  (multiple)  Lows  to  (multiple) 
Highs.  Even  though  abstract  composition  problems 
have  been  well  studied  [6],  this  paper  shows  that  the  ac¬ 
tual  design  of  such  a  device  is  quite  complicated.  This 


secure  device  should  not  only  meet  the  requirements 
of  conventional  network  routers  such  as  performance, 
reliability,  and  fairness,  but  also  the  requirements  of 
security,  such  as  minimal  impact  from  covert  channels 
and  denial  of  service  attacks.  The  network  Pump  that 
was  introduced  in  this  paper  can  balance  the  above 
requirements. 

This  paper  emphasizes  the  design  and  the  rationale 
behind  these  design  decisions.  We  also  back  our  claims 
through  the  preliminary  simulation  results. 

Our  future  plan  includes  designing  and  building  the 
network  Pump  on  top  of  the  ATM  layer. 
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